[Previous] [Next] [Index]
[Thread]
Re: Java security problems (fwd from Risks Digest #17.77)
(I posted this to comp.risks and to comp.lang.java a couple days ago.)
--
This posting is a response to the DNS Spoofing attack described on
http://www.cs.princeton.edu/~ddean/java/.
Background
-----------
A bit of background on DNS: (apologies for the oversimplification)
DNS is the internet "Domain Name Service". It provides the mapping
between computer names and computer addresses. For example, the name
ds.internic.net has the 3 IP addresses, 198.49.45.10, 192.20.239.132,
and 204.179.186.65. Probably, each IP address eventually is mapped
onto a different computer, although multiple IP addresses could also
map onto a single computer. The reason for many-to-many
name-to-address mappings is that it enables system administrators to
balance the network load on their machines. The name ds.internic.net
is probably accessed hundreds of thousands of times every day by
people all over the network, so it makes sense for that one name to be
served by multiple machines with multiple IP addresses.
Let's use the term "DNS spoofing" to mean that a computer on the
internet has been able to advertise a false IP address for itself.
DNS spoofing isn't directly related to Java, but might be used as part
of a Java attack applet.
Attack
-------
The attack scenario is like so.
1) The machine evil.hacker.com advertises two IP addresses for
itself, the real IP address for that machine (say 1.1.1.1) and a fake
IP address for that machine (say 6.6.6.6). The fake IP address is
actually the address of target.com, which is the computer the attack
applet wants to try to connect to, later on.
2) Someone using a Java-powered browser loads an applet from
evil.hacker.com. Now, applets are allowed to make network connections
only to the machine they came from, which in this case is
evil.hacker.com. However, this attack applet tries to open a
connection to the computer named "target.com".
3) The applet security manager does a DNS lookup on the name
target.com, and checks if its IP address is in the pool of IP
addresses that this applet is allowed to connect to. It gets the
address 6.6.6.6. It turns out that this is one of the two addresses
associated with evil.hacker.com, and so the connection is allowed.
The connection should not be allowed.
Why is this attack possible?
----------------------------
There are two reasons why this DNS Spoofing attack works:
1) It's relatively easy for someone to advertise false IP
addresses. That is, it's relatively easy for someone
to run their own domain name resolver.
2) The applet security manager allows an applet to connect
to any of the IP addresses associated with the name
of the computer that it came from.
What's the fix?
----------------
The right solution for this problem is to make the Domain Name Service
more secure. It shouldn't be so easy for anyone to advertise false
names or false addresses.
A fix for the applet security manager is to be more strict about
deciding which computers an applet is allowed to connect to. The Java
system needs to take note of the actual IP address that the applet
truly came from (getting that numerical address from the applet's
packets, as the applet is being loaded), and thereafter only allow the
applet to connect to that exact same numerical address. Additionally,
the Java system could be even stricter than that, by declaring that an
applet can only connect to the same port number that it came from, in
addition to only being allowed to connect to the same IP address that
it came from.
What's the bottom line for me today?
------------------------------------
An applet on its own cannot carry out this attack. It would have to
be working in conjunction with a hacked DNS server owned and ascribed
to some domain.
Also, the attack applet would have to know the name and IP address of
machines inside a corporate firewall, in order to try to establish a
connection to machines behind the firewall.
Sun will be distributing a patch to the applet security manager to
implement the more rigorous checking described above. That fix will
be available within a few days, and it will be distributed in source
code and in bytecode format.
Follow-Ups:
References: